Usually I tend to prefer some parameter handling at the start of the function, such as:

if nan_as_null is None:
    nan_as_null = True

@mroeschke - The CI failure is a result of us hitting this check when we call compute() in the dask-cudf test.

When a dask collection is "computed", the partitions need to be concatenated together. It seems that calling cudf.concat uses the cudf.Series._concat, which in turn calls this as_column function with a default nan_as_null=True setting. This means that dask-cudf correctly uses the user-provided nan_as_null=False option when each partition is converted from pandas to cudf, but then the nans are lost when the partitions are concatenated together in compute.

One possible fix may be to modify this line to something like:

 return cls(data=col, index=index, name=name, nan_as_null=False)

However, I'm not immediately sure if there are other corner cases that this doesn't catch.

Also, I suppose the best way to test this outside of dask is to add a cudf.concat test that checks that existing nan values are preserved. In the case that there are both nan and null values, then we would probably need to raise an error or "promote" everything to null.

Thanks for the insight! The Series._concat piece is what I was missing. I am going to see what breaks if nan_as_null is set to False. In theory, I would imagine nans and nulls should not be mangled together when merged together